Fixes #162

How import statements are currently treated

Let's use this simple export as an example:

// Foo.ts
import { DirectoryAddOptions } from "ts-morph";
export interface Foo {
  options: DirectoryAddOptions
}

For every export found within Foo.ts, the ts-auto-guard library will generate an accompanying guard for the exported variable. Regardless of how many exports are found, all guards are placed within the guard file: Foo.guard.ts.

Each property of the exported variable is analyzed to determine its type. In our example above, we only have one exported variable Foo which has a single property options. The expected guard file produced is as shown:

// Foo.guard.ts
/*
 * Generated type guards for "Foo.ts".
 * WARNING: Do not manually change this file.
 */
import { Foo } from "./Foo";

export function isFoo(obj: any, _argumentName?: string): obj is Foo {
    return (
        (obj !== null &&
            typeof obj === "object" ||
            typeof obj === "function") &&
        (obj.options !== null &&
            typeof obj.options === "object" ||
            typeof obj.options === "function") &&
        (typeof obj.options.recursive === "undefined" ||
            obj.options.recursive === false ||
            obj.options.recursive === true)
    )
}

NOTICE: There is no reference of DirectoryAddOptions within this guard file. That is because ts-auto-guard doesn't need it! It ONLY requires referencing the named type of a variable if it is a class. In our example, DirectoryAddOptions is an interface.

The Issue : #162

If we instead change the options variable to a class type, like Directory, we encounter some problems.

// Foo.ts
import { Directory } from "ts-morph";
export interface Foo {
  options: Directory
}

// Foo.guard.ts
/*
 * Generated type guards for "Foo.ts".
 * WARNING: Do not manually change this file.
 */
import { Directory } from "../node_modules/ts-morph/lib/ts-morph";
import { Foo } from "./Foo";

export function isFoo(obj: any, _argumentName?: string): obj is Foo {
    return (
        (obj !== null &&
            typeof obj === "object" ||
            typeof obj === "function") &&
        obj.options instanceof Directory
    )
}

As you can see, the guard file references the package ts-morph with a relative path within node_modules. This does not follow the TypeScript convention for non-relative package imports. In some cases, these relative imports do not correctly import the desired variable. This PR aims to address these problems with relative class imports.

The Fix

This PR adds a check for each import statement being added to the guard file. If the accompanying import is found within the node modules directory, it will explicitly copy the reference found within the source file. For our above example, we grab the package reference ts-morph found in Foo.ts. This solves our problem of referencing npm modules.

One alternative method, which was NOT used, was to copy the entire import statement found within the source file. However, this was discouraged as it has the potential to include more variables than necessary within the guard file. For example, a file like:

// Bar.js
import { Directory, DirectoryAddOptions } from "ts-morph";
console.log(DirectoryAddOptions)
export interface Bar {
  dir: Directory
}

will produce the guard file:

// Bar.guard.ts
/*
 * Generated type guards for "Foo.ts".
 * WARNING: Do not manually change this file.
 */
import { Directory, DirectoryAddOptions } from "ts-morph";
import { Bar } from "./Bar";

export function isBar(obj: any, _argumentName?: string): obj is Foo {
    return (
        (obj !== null &&
            typeof obj === "object" ||
            typeof obj === "function") &&
        obj.options instanceof Directory
    )
}

NOTICE: we import DirectoryAddOptions even though it is not used anywhere. This will raise an error for users with the TypeScript compiler option: noUnusedLocals. Therefore, I consider it a non-solution.

Testing

The current tests use an inMemoryFileSystem for generating test projects. However, this does not adequately simulate a project containing node-modules. Therefore, I created another test file to auto generate a local file for every test. This file ImportTest.ts is created and destroyed for every test to eliminate contamination between tests. It's written into the local directory /tests each time.

Since it lives in the local file system, within the local TypeScript project, we can adequately test class imports from npm packages already found in the ts-auto-guard project. The use of the ts-morph package for tests was chosen because this project already heavily relies on ts-morph types. Therefore, it is highly unlikely to be removed in the future, preventing test failures.